



\documentclass[conference]{IEEEtran}

\usepackage{graphicx}  % Written by David Carlisle and Sebastian Rahtz
                        % Required if you want graphics, photos, etc.
                        % graphicx.sty is already installed on most LaTeX
                        % systems. The latest version and documentation can
                        % be obtained at:
                        % http://www.ctan.org/tex-archive/macros/latex/required/graphics/
                        % Another good source of documentation is "Using
                        % Imported Graphics in LaTeX2e" by Keith Reckdahl
                        % which can be found as esplatex.ps and epslatex.pdf
                        % at: http://www.ctan.org/tex-archive/info/
\usepackage{trackchanges}
\renewcommand{\initialsOne}{Jiang}
\renewcommand{\initialsTwo}{Remzi}
% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex).         ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.


% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor IEEEtran}


\begin{document}

% paper title
\title{Off-the-Record Instant Message \\ for group conversation}


% author names and affiliations
% use a multiple column layout for up to three different
% affiliations
\author{
\authorblockN{Jiang Bian}
\authorblockA{Department of Computer Science\\
University of Arkansas at Little Rock\\
Little Rock, Arkansas 72004\\
Email: jxbian@ualr.edu}
\and
\authorblockN{Remzi Seker}
\authorblockA{Department of Computer Science\\
University of Arkansas at Little Rock\\
Little Rock, Arkansas 72004\\
Email: rxseker@ualr.edu}
}




% make the title area
\maketitle

\begin{abstract}
Instant messaging (IM) is becoming an integral part of social as well as business life. The main concern with IM is that the information is out in the open (unless the IM system is contained within a VPN). Off-the-record (OTR) protocol is designed to enable IM users to have private conversations. However, OTR protocol  currently cannot support multi-user chat rooms via IM services and there is a need for a product that enables parties to meet in IM-based, virtual, and encrypted chat rooms. Such a product would be beneficial to small businesses especially. This paper shows how the OTR protocol can be extended to support multi-user conversations. The case study which follows, involves a proof of concept plug-in developed for GAIM (an open source IM client that supports multiple protocols), and implementation details for the plug-in. 
\end{abstract}

% no keywords

% For peer review papers, you can put extra information on the cover
% page as needed:
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
%
% for peerreview papers, inserts a page break and creates the second title.
% Will be ignored for other modes.
\IEEEpeerreviewmaketitle

\section{Introduction}
% no \PARstart
Instant Messaging (IM) is the most popular message exchange system around the world nowadays. IM systems are becoming available even on cellular phones. More and more mobile devices support at least one IM technology and these technologies are being utilized for business solutions. Given the status quo of measures implemented for the protection of users’ privacy or intellectual property, there is much room for improvement.

Users seem to prefer IM systems because they are not as intrusive as phone calls, yet are more interactive than e-mails. Some of the popular IM systems include: Microsoft's MSN (or Windows) Messenger (MSN) \cite{re:msn}, American Online Instant Messaging (AIM) \cite{re:aim}, Google Talk \cite{re:google-talk}, etc. and these systems are changing the way people communicate with friends, family and business partners. However, till recently, confidentiality support has been missing in the IM environment. Most IM protocols were implemented on the top of the existing public Internet service, where there is no guarantee of the secrecy of the transmitted IM messages. Even two users who are sitting beside each other, the IM messages may still travel a path through several routers and these messages are almost open to any knowledgeable eavesdroppers—when there is no proper encryption and/or authentication. Moreover, besides eavesdropping, all the other potential vulnerabilities such as: account hijacking, man-in-the-middle attacks, denial of service, etc. that exist in current distributed network applications can also be applied to IM systems.

As IM systems become part of the social and business infrastructure, concerns related to protecting the content of messages arise. The discussion of privacy in this paper will be limited to protecting the intellectual property of small businesses. The reason for focusing on small businesses is that, a vast majority of them cannot afford buying the services that can ensure secrecy of their intellectual property which could help keep their competitive advantages.


\subsection{IM system's architecture}

One could probably consider Internet Relay Chat (IRC) \cite{re:irc} as the first IM system. IRC provides a real-time communication service among a group of people regardless of their physical locations. In IRC, each participant needs to connect to a centralized IRC server and join a conversation channel (or topic). There are two types of conversations in IRC: one is public  (i.e. which messages could be read by everyone in the same channel) and the other is private (i.e. that messages are exchanged between only two people, who may or may not be on the same channel) [3]. Later on, the true IM systems such as AIM, MSN, ICQ, Yahoo Messenger, and Google Talk etc. appeared. These systems share an identical concept and provide similar functionalities: real-time chat (peer-to-peer or/and chat room) and file transfer.

Instant Messaging is a typical client-server distributed application and as such can be partitioned into  two fundamental communication models: 

\begin{itemize}
\item \textbf{Client-Server-Client:} All messages exchanged among participants need go through a centralized server. No matter whether the messages are system messages (i.e. the messages that are taking place between the client and the server to exchange status information like: users’ buddy lists, IP addresses, client status, etc.) or the actual conversation payload.

\item \textbf{Peer-to-Peer:}  Only the system query and control messages are exchanged between the clients and the server. When initiating a conversation, one party  should query the server first to get the another's IP address and use this information to establish an private connection between them. In this model, the server's only responsibility is to store all the clients’ information, which might vary from different IM systems, but all include information such as: users’ profiles, clients' IP addresses, client version, etc. Moreover, the servers should also provide a querying service in order to let the clients retrieve this information.
\note[Remzi]{Is this not the case for the client-server-client too???}
\note[Jiang]{Well, it's true. I just want to emphasize that no real messages are going through the server. Probably, we need rearrange the words.} 
\end{itemize}

\subsection{Potential Vulnerabilities}
The message packages in public IM systems need to traverse through the public Internet regardless of the model and structure utilized. In general, these messages are not encrypted and an eavesdropper could easily stand on one router between the IM users, sniff their communication and read their messages. Retrieving the contents of IM messages is a rather trivial task once one grabs the packets traversing in the network. This is especially true on a LAN network, where all the packages are broadcast and every one could hear each other’s voice. It becomes a little more inconvenient for an eavesdropper if the LAN network is switch based, but even then the eavesdropper could sniff the traffic from the line that connects the switch to the router. There are also lots of other mechanisms available for sniffing traffic on a switched LAN; however, it is beyond the scope of our paper. The discussion about an eavesdropper sniffing traffic is to justify the need for protecting the content of the IM messages via encryption. Nonetheless, the problem still remains as to how one would distribute the encryption keys, as well as, how the identity of a user can be verified.

\textit{Account Hijacking} is another famous attack which could be found in many IM systems. In such an attack, an attacker hijacks another user's IM account and impersonates that user in subsequent conversations with others.. The reason this attack is so successful, is because most of the IM systems have been using vulnerable authentication mechanisms. Session identifiers widely used by most of the IM protocols are not difficult to forge. An attacker could produce a similar legal key in accordance with the identifier's format. 

\textit{Man-in-middle attack} is another type of attack, that is feasible within IM systems because of improper key exchange schemes. For instance, the Diffie-Hellman [4] key agreement protocol, which is used by lots of IM security products, is vulnerable to such an attack. Suppose Alice and Bob want to communicate privately and Alice initiates the Diffie-Hellman key exchange protocol. However, an eavesdropper, Carol, intercepts Alice's public key and sends her own public key to Bob. When Bob replies, Carol gets Bob's public key, substitutes it with hers and replies to Alice. After all, Alice and Bob will think they are sharing a private secret with each other and all their messages encrypted by this secret are safe. But in fact, they are talking through a middle-man, in this case it is Carol who is reading all the messages. Carol could even go one step further: modify the messages and then re-encrypt with the appropriate key before delivering to the other party. This vulnerability occurs because there is no authentication scheme used in Diffie-Hellman key agreement protocol. And one possible solution is to add fingerprints (or digital signatures) to each message. 

The above mentioned security issues in the IM environment are usually addressed by adding encryption and authentication (e.g. users authenticating one another). Nevertheless, using only confidentiality and authentication are not good enough to provide an off-the-record (OTR) conversation environment, in which the deniability property is also satisfied. In 2004's WPES, Borisov, N., et. al. proposed and implemented the OTR protocol \cite{re:borisov:04}. And, in a later version of the OTR protocol, a security flaw pointed out by Raimondo, et al \cite{re:mario} was fixed. OTR has two distinguishable security properties: perfect forward secrecy and deniability. These features will be discussed in the next section (Section \ref{se:background}). 

This paper is composed of four sections and the remaining sections are organized as follows:Section \ref{se:background} presents a introduction of current popular mechanisms used for secure Instant Messaging; Section \ref{se:otr} discusses the main concepts behind the OTR project and signifies the need for chat room support, a feature missing in the OTR protocol; Section \ref{se:methodology} presents our implementation of secure group conversation based on the OTR protocol. Conclusion and future work are given in Section \ref{se:conclusion}. 
 
\section{Related Work}\label{se:background}
%%\textit{"Have you ever noticed that your instant messaging conversations 
%%re plaintext over the public network?"} \\
Security in distributed applications is supported by a set of security services. The International Organization for Standardization (ISO) defines five typical security services: access control, identification/authentication, confidentiality, integrity, and non-repudiation \cite{re:iso-security}. However, for IM systems, some security features need to be reconsidered, especially, non-repudiation. In order to enable IM users to talk off-the-record, deniability (repudiation) instead of non-repudiation is needed. In other words, a user should have the ability to deny what he or she said in the past. Several open source projects and some commercial software have addressed the security weaknesses that exist in the current IM systems. Security in these applications is in general, supported by adding encryption and authentication schemes. 
We will state a few of such IM clients that are in use today. Our focus is those that support or promise to support encryption and/or authentication. A complete survey of all the clients is beyond the scope of this paper.
SimPro \cite{re:simpro} is commercial software developed by Secway, a European company, providing privacy protection in IM systems. It includes: 

We will state a few of the IM clients that are in use today. Our focus is those that support or promise to support encryption. A complete survey of all the clients is beyond the scope of this paper. 

SimPro \cite{re:simpro} is a commercial software developed by Secway, a European company, providing privacy protection in IM systems. It includes:
	\begin{itemize}
		\item Encryption of messages
		\item Key infrastructure support for user authentication
		\item Encrypted file transfers for MSN and ICQ/AIM
		\item Secured recording of conversations
	\end{itemize}
Moreover, encryption algorithm and authentication key agreement can be customized by the users. The symmetrical algorithms:AES (128 bits), 3DES (Tripe DES, 128 bits), CAST (128 bits), Twofish (128 bits) and Serpent (128 bits), are provided for encrypting messages; and the asymmetrical algorithms such as, RSA (2048 or 4096 bits), Diffie-Hellman, ElGamal/DSA, and Elliptic curves, are used for authentication and key agreement. In addition, SimpServer is a lightweight IM security gateway for UNIX systems developed by the same company. All the network packages in the SimpServer system are automatically encrypted before transmitting.

Google Talk \cite{re:google-talk} system currently does not support IM encryption. The only security property claimed in Google Talk is that IM conversations will not be logged in the user's Gmail account which is not helpful at all. Yet Google Talk is still in beta version and encrytion support is planned to be provided for the official release. \note[Jiang]{Shall we talk about google talk? since it does not provide any meaningful security support.}

%\textsc{MENTIONING TRILLIAN BRIEFLY...}%
%Trillian is another IM client with multi-protocol support (like SimPro) [[[Reference to http://www.ceruleanstudios.com/learn/]]]. Trillian supports encrypted IM communication for AIM and ICQ protocols.  
%
GAIM is an open source, multi-protocol IM client and it is available for Linux and Windows operating systems \cite{re:gaim}. Adium X can be considered GAIM's implementation for Apple's OS X since Adium uses GAIM library for supporting IM protocols. 

Gaim-Encryption \cite{re:gaim-encryption} is a security plug-in for GAIM and it uses NSS (Network Security Services) to provide transparent RSA encryption. It can automatically generate the public/private key pairs upon loading the plug-in. It also can automatically exchange the public keys during the initiation of conversations. Although Gaim-Encryption does not provide choice of encryption algorithms, it can be used as a wrapper and extended to support different encryption algorithms. Obviously, without authenticating the participants, it suffers from man-in-the-middle attacks. 

Gaim-e is another encryption plug-in for GAIM. It uses GNUPG (GPG) to securely transfer the session keys encrypted with RC5, a block cipher notable for its simplicity \cite{re:rc5}. The Gaim-e plug-in currently works with AOL, MSN, and Yahoo IM systems (at the time of this writing, other protocols have not been tested) \cite{re:gaim-e}.

Trillian is once more another IM client software with multi-protocol support (like GAIM) \cite{re:triliian}. And it claimed to support encrypted IM communication for AIM and ICQ protocols. \note[Jiang]{Shall we get it longer?}

As the brief survey above shows, most of the available products for IM security address only part of the security services defined necessary by the ISO. Often, message integrity, perfect forward secrecy, and deniability are not addressed. The next product we will survey addresses these widely omitted concerns within the IM domain. 

\section{Off-the-Record (OTR) Instant Messaging System}\label{se:otr}
Borisov, N., et. al. proposed a comprehensive solution, the OTR protocol \cite{re:borisov:04}, to address the weakness in current IM systems. Practically, they implemented a plug-in for the popular open source, multi-protocol IM clientGAIM, and a local proxy which can be used by other IM clients. The OTR protocol is based on the Deffie-Hellman key exchange agreement between the two parties who want to communicate, and all the applications are designed for only two parties. Under the OTR conversation environment, users can use most of the popular IM systems, such as MSN, AOL, and Yahoo, etc. and chat in a secure way. 

\subsection{Basic concepts behind the OTR}
The OTR protocol contains four basic cryptographic primitives:  \\
\textbf{Perfect forward secrecy} \cite{re:jablon96strong} Confidentiality (i.e. only the two communicating parties, Alice and Bob, should be able to read the conversation messages), is introduced by using short-lived encryption/decryption key(s). The basic idea is that the two parities, Alice and Bob, should forget used keys after they process the old messages (an old message is a message for which the encryption-transmission-decryption cycle is completed). And, it is computationally infeasible to generate used keys from the current key and long-term keys. The mechanism guarantees that even if an eavesdropper is lucky enough to get the current key and compute the shared secret in use at the moment, it is still impossible to decrypt and read previous messages by using the compromised current key. OTR uses the well known Diffie-Hellman key agreement protocol \cite{re:diffie-hellman} to provide perfect forward secrecy. Each key is used to secure one message only and a new key is used for transmitting the next message securely. \\

\textbf{Digital signatures and non-repudiation} - Digital signatures are used to make up for the lack of authentication in the Diffie-Hellman key agreement protocol. It is a popular approach in authentication protocols to use digital signatures that act as long-lived keys. These long-lived keys are solely for authentication purposes and are not used to encrypt IM messages in the OTR protocol. However, the signature along with the message leads to another problem. It enforces the non-repudiation property that the signatures can be verified by a third party without the cooperation of the owners, and this property conflicts the deniability service required by an OTR IM session. The solution to this problem is to use a Message Authentication Code (MAC) to authenticate IMs instead of the user's digital signature. In other words, the digital signatures authenticate the keys instead of the IMs and authentication of keys provides the identification service, because only the person who has the right key can read the cipher texts. In the implementation, the previous key is used to authenticate the new key at every key refreshing stage. \\

\textbf{Message Authentication Code (MAC) and deniability} - Deniability is the ability to deny the content of conversations and it is addressed in the OTR protocol by using MACs. The way to generate each MAC is to use a one-way cryptographic hash function with a secret MAC key shared by conversation members. Alice uses her copy of the MAC key to compute a MAC of her message, and sends this MAC along with her message over a secure transmission channel; Bob verifies the integrity and authenticity of the message by computing the MAC for the received message using his copy of the shared MAC key and comparing with the MAC sent by Alice \cite{re:borisov:04}. Deniability is provided by using MACs for IM: Carol, a third party, cannot prove that the message was sent by Alice, since she does not know the MAC key shared between Alice and Bob. Bob cannot even prove to a third party that the message really came from Alice, because both of them know the MAC key, and the message could have been forged by Bob.

\textbf{Malleable encryption and forgeability} - Forgeability, a stronger property than repudiation is provided by the OTR. Once the keys used to encrypt messages expire, the associated MAC keys for message authentication are revealed. The reason for revealing old MAC keys is to allow forgeability of messages for which their encryption keys have expired. This feature enhances the ability of Alice to deny that the messages were sent by her, because anyone could calculate a MAC  based on a modified message (even though it's encrypted) and validate it with one of the revealed MAC keys. OTR protocol uses a malleable encryption scheme (i.e. any change made to a cipher text will cause a meaningful change in the right position of the plaintext). Revealing of MAC keys together with a malleable encryption scheme, give a third party the ability to forge the messages sent by Alice and hence give Alice the ability to deny sending those messages. Moreover, anyone who recovers the MAC key in the future is unable to verify the authenticity of the messages sent in the past, which means even somebody can read the messages but cannot prove who wrote the messages. \\

\subsection{Security Weakness in OTR}
Mario Di Raimondo, et al. \cite{re:mario} pointed out three major security flaws or vulnerabilities in the OTR protocal:   	
	\begin{enumerate}
	\item An authentication failure
	\item A key refreshment flaw 
	\item The unreliable support of the deniability
	\end{enumerate}
All these three weaknesses are caused by the inappropriate choice of the key agreement protocol.

Because of improperly choosing  to use signed keys authentication protocol which is adopted from DH protocol, the OTR suffers a possible man-in-the-middle attack. For example, suppose Alice, Bob and Eve are in the same channel. The key ($g^{x}, Sign_{Alice}(g^{x})$) sent from Alice to Bob could be passed on by Eve to Bob but this time with her own digital signature (i.e. under Eve's name). When Bob receives the signed key, he thinks that he is talking to Eve, and sends a response of the signed key under his name. Once more, Eve relays this message to Alice and gets Alices reply. After all, Alice thinks Bob is on the other side, but acutally it is Eve who is talking to him. On the other hand, one simple solution is to include identity information in the digital signature, but it will definitely dismiss the deniability property.

Moreover, the revealing of an ephemeral private key could cause an impersonation attack. An attacker could easily relay the message to Bob, $g^{x}, Sign_{Alice}(g^{x})$, which was received from Alice, and he/she could compute the session key upon whatever $g^{y}$ (i.e. Bob's pubic key) responded from Bob. And this session key will be valid as long as the long-term private key of Alice is not revoked. Definitely, this flaw defeats the goal of a  secure and well-designed key protocol, which as we all know, the only way for a devil impersonate into the conversation is the disclosure of the long-lived private key rather than a piece of information used in the session. Therefore, they suggest doing a full key refreshment periodically, which ensures that the revealing of an ephemeral private key will not affect the next fully-refreshed conversation.

Furthermore, the improper mechanism of revealing MAC keys weakens the secrecy of encryption keys. Since the MAC keys are generated as a one-way hash over the encryption key, the attacker can easily use this knowledge to mount a "dictionary attack", although it is probably computationally too expensive. And, the choice of using stream cipher may also cause troubles, especially, when one is trying to manage the encryption counters to avoid re-use of conter values.

Consequently, they suggested three alternative AKE (Authentication Key Exchange) algorithms, SIGMA, SKEME \cite{re:skeme:96} (i.e. which is a ealry voice of a protocal designed to provide deniability to IPsec's IKE protocol.) and HMQV, and discussed both the advantage and disadvantage of using these three protocols. 

This discussion leads the OTR researchers to reconsider their design, which resulted in a  second version of the OTR protocol \cite{re:otr-protocol}, where: 
	\begin{enumerate}
	\item They fixed the identity-binding flaw (the impersonate attack vulnerability) simply by adding an additional identification message at the beginning of the conversation session. 
	\item No longer revealing the users' public keys to passive eavesdroppers and this helps in privacy-preserving for the internal application's OTR messages.
	\item And, additionally, make a support of fragmentation OTR messages, since a lot of Instant Messaging protocols have limitation on each message's size.  
	\end{enumerate}

\note[Jiang]{I rewrote it, check it out.}

\subsection{Lack of Chat Room Support}
Chat room systems are also being utilized by businesses to increase efficiency. A chat room system is more suitable for online discussions than conventional mailing-list systems due to its interactive nature. Many small businesses use chat room systems (and/or IM systems) for daily business discussions, customer service, etc. Using such technologies cuts down the operation costs of a business and enables employees to multi-task when necessary. Many open source projects use chat room systems to conduct development meetings, since most open source projects are developed by programmers located in disparate locations. There is, however, no privacy protection in most current chat room systems. Security concerns associated with chat rooms limit their use for many businesses. 

Some IM systems have chat room support built into them. For example, MSN and Yahoo IM protocols support the chat room concept and once a user invites another user to an ad-hoc chat room, they can invite other parties to have a meeting in that established chat room. Considering security related issues (associated with both IM systems and chat rooms) mentioned previously, it would be beneficial to extend the OTR protocol to support a secure chat room facility. 

A secure chat room that utilizes the existing IM infrastructure would bear virtually no cost on the participants. An IM-based secure chat room will also avoid the need for a VPN or dedicating a local server and the challenges that come with having such systems and their management. Hence, we extend the OTR protocol with a scheme to support multi-party conversations and implemented a GAIM plug-in. Our implementation currently supports secure chat room over the MSN IM protocol. 


\section{Methodology and Implementation}\label{se:methodology}
\subsection{Initial thought}
The main concept of our implementation is to make a virtual server. What we mean by the term virtual server, is that one of the participants is acting as a server in the chat room. The server, which can be any one of the participants in the conversation session, will perform key exchanges with every other participant—the same way as if he/she would for a regular peer-to-peer OTR conversation. Therefore, the virtual server is sharing a secret with each other chat room members. In other words, every one other than the virtual server itself will establish a private channel with the host, each having its own shared secret with the host. The virtual server is responsible for routing and broadcasting all Insant Messages, which means the virtual server needs to transfer all the messages from one chat room member to every one else, as shown in Figure \ref{fig:schema2}.

For example, in the chat room, we have three chat members Alice, Bob and Carol, and suppose that Alice is the virtual server. So, after all the key exchange processes conclude, we should have:
\begin{itemize}
\item Bob and Alice have a shared secret $SS_{Alice-Bob}$.
\item Carol and Alice have a shared secret $SS_{Alice-Carol}$.
\end{itemize}

\begin{figure}
\centering
\includegraphics[width=2.5in]{schema2.eps}
% where an .eps filename suffix will be assumed under latex, 
% and a .pdf suffix will be assumed for pdflatex
\caption{Schema 2: Make a virtual server in the middle}
\label{fig:schema2}
\end{figure}

There comes to a \\
\textbf{Problem:} \textit{How can Bob communicate with Carol?} \\
Bob can not send his OTR messages directly to Carol since the two do not have a common secret, and if he did, Carol would not be able to decrypt his messages. It is true that they could start their own OTR session and talk to one another without Alice knowing (Alice would not be able to see their messages). But either way will defeat the purpose of a chat room. (i.e. every one in the same chat room should have the same screen of conversations.) However, both Bob and Carol have a shared secret with the Virtual Server, Alice, therefore Bob can send the OTR messages to Alice first. And then Alice could decrypt Bob's messages by using $SS_{Alice-Bob}$, re-encrypt them with $SS_{Alice-Carol}$ and send them to Carol. And now Carol has no problem to decode the messages and read them. All of our implementation is based on this simple idea.

\subsection{Detail Design}
The MSN Messenger \cite{re:msn}, developed by Microsoft, was released in July, 1999. It became popular with the wide use of the Windows operating system. The end users' MSN applications are called an "MSN Client"; it connects to the "MSN Server" hosted by Microsoft to acquire information about the user's personal profile, buddy list and so on. Whenever a user modifies his/her profile, the client sends this information to the server and the server notifies other users in your buddy list.

The MSN protocol has built in support for chat rooms. There are no major differences between a two-party conversation session (referred to as 'SwitchBoard') and a chat room session other than the number of users in the session. If one user wants to invite another one to the chat room, she will query the \note[Remzi]{NAME SERVER?????????????} \note[Jiang]{No, it's just the name they give to the server} by sending an invite command and the invited user will receive an RNG command containing the session id, buddy list of the chat room, etc. Notice that, all messages exchanged in the chat room session are broadcast to every user along with sender's account name, the message body and the timestamp.  

\textbf{Design Problem 1:} \\
The MSN IM protocol specifies that messages sent out in a chat room are broadcast to every user in that session automatically. Therefore, in our design, it is hard to tell the real receiver of the message (the virtual server). In our virtual server scenario, a user only has the capability to decrypt the instant messages coming from the virtual server and all messages come from other users are meaningless to him (a user in that session has a common secret only with the virtual server). Hence, we need an identifier at the beginning of a message to identify the receiver of the message. If the user receives an IM that is not for them, the user could simply discard it, since this message is not encrypted with the key they know and they would not be able to read it. 

We will now show some more examples of our implementation. Assume we have an OTR chat room via MSN IM system with three users: Alice, Bob, and Carol. Again, suppose that Alice is the virtual server for this secure chat session. And therefore, after the key exchange processes, as we said in the previous example:

\begin{itemize}
\item Bob and Alice have a shared secret $SS_{Alice-Bob}$.
\item Carol and Alice have a shared secret $SS_{Alice-Carol}$.
\end{itemize}

\textbf{Example 1:} \label{ex:example1}\\
Alice, the virtual server, sends a message (no matter what messges, including OTR system messages, which are used for key management) to Bob; and the message should be encrypted with $SS_{Alice-Bob}$ and formatted into the following manner: 
\begin{center}
\begin{verbatim}
Alice->Bob:
?RECV?Bob@hotmail.com?ENDRECV?
 + <Encrypted Message>
\end{verbatim}
\end{center}
When Carol receives this message, she will check the tag (i.e. prefix of the encrypted messages) first and see the message is not hers (i.e. in terms of she can not decrypt it and read it) according to the account name in between 'RECV' and '?ENDRECV?' markers, she should just discard this message. Then, when Bob receives the same message, and after he checks the tag and finds out that the message does belong to him, he will send this message to the OTR message encryption and decryption routine (using the OTR library) and use the secret shared between him and Alice ($SS_{Alice-Bob}$) to decode this message. 

\textbf{Example 2:}  \label{ex:example2}\\
Bob says something in the chat room, but Carol could not read it, since the two do not have a common shared key. Hence, Bob has to send his message first to the virtual server, Alice, with the receiver tag [Alice@hotmail.com]. 
And the message will be something like this: 
\begin{center}
\begin{verbatim}
?RECV?Alice@hotmail.com?ENDRECV?
 + <Encrypted Message from Bob>
\end{verbatim}
\end{center}
When Alice receives the message, she will decrypt it with the key she shared with Bob ($SS_{Alice-Bob}$), write the message to her screen, then encrypt it again with $SS_{Alice-Carol}$ and set Carol to be the receiver as: 
\begin{center}
\begin{verbatim}
?RECV?Carol@hotmail.com?ENDRECV?
 + <Encrypted Message from Alice>
\end{verbatim}
\end{center}

On the Carol's side, she will receive both messages encrypted with different keys, one from Bob and another one from Alice. She will simply dismiss the first, since she does not known the right key; but process the second one to the decryption routine and retrieve the decoded content of the message.

It seems to be perfect, but there remains another issue: \\

\textbf{Design Problem 2:}\\
Since the server is basically a router and responsible for reformatting and transferring all the messages, it is really impossible to know the real sender without any additional effort. Let us continue with the previous example: When Carol gets the message from Alice, the virtual server, although she could decypher the message without any problem, she has no idea who is the real sender. This is because of that the messages do not contain any information that indicates the real sender. And therefore, Carol may think this message was come from Alice, but actually it was said by Bob. There is no such support for "message tracking" or "transitive authentication" in either the MSN protocol or GAIM project. The solution we propose is to add another tag after the receiver tag to indicate the real sender. And in accordance with the previous example \ref{ex:example2}, now the messages will appear to be the following format: \\

Part One: Message from Bob to Alice
\begin{verbatim}
Bob->Alice:

?RECV?Alice@hotmail.com?ENDRECV? 
+ ?SEND?Bob@hotmail.com?ENDSEND?
+ <Encrypted Message>
\end{verbatim}

Part Two: Retransfered message from Alice to Carol

\begin{verbatim}
Alice->Carol:

?RECV?Carol@hotmail.com?ENDRECV?
+ ?SEND?Bob@hotmail.com?ENDSEND?
+ <Encrypted Message>
\end{verbatim}
Till to this point, all the messages should include all the necessary tags to identify both the real sender and the receiver.  \\

\textbf{Design Problem 3:}\\
This problem arose because of a "weakness" in the MSN IM protocol. In the MSN IM protocol, every one in a chat room has the same privilege, which means there is no identifier for who is the "owner" of the chat room established via the MSN IM server. Every one in the chat room can invite another buddy without restriction. Since we would like to offer participants a degree of security via OTR, we worked around this problem in the following way: Some additional information about the chat room is written in a file named \textit{otr.chatinfo} located in the \textit{.gaim} folder, which is used by GAIM. The file has the following format: 
\begin{center}
\begin{verbatim}
?AC?[account name]	?CID?[chat_id]	?HOST?[host name]		?STAT?[security level]
\end{verbatim}
\end{center}
\textbf{AC}: indicate the account name of the user who owns the current conversation window. \\
\textbf{CID}: \verb#chat_id# is used by GAIM to identify different chat rooms. \\
\textbf{HOST}: the user who made to be the virtual server for the MSN chat session. \\
\textbf{STAT}: indicate the security level used by OTR library; the security level can be:
\begin{itemize}
		\item 0 indicates no private conversation.
		\item 1 indicates private session over.
		\item 2 indicates private session.
\end{itemize}
Implementation Assumptions: \\
The user who begins the conversation session, (the user who clicks the OTR button and sends out the OTR query to start the private OTR session) would be the server. For example: Alice wants to start a private conversation, so her \textit{otr.chatinfo} will look like:
\begin{center}
\begin{verbatim}
?AC?Alice@hotmail.com	?CID?1	?HOST?Alice@hotmail.com	?STAT?2
\end{verbatim}
\end{center}
For all other users (other than the virtual server), for example Bob, when he receives the first OTR query message indicating a request of private conversation from Alice.  Bob will write the following information to his \textit{otr.chatinfo} file:
\begin{center}
\begin{verbatim}
?AC?Bob@hotmail.com	?CID?2	?HOST?Alice@hotmail.com	?STAT?0
\end{verbatim}
\end{center}
Notice that the conversation's security status is initiated to be 0 (not private). After they finish the first key exchange round and establish a private communication channel, the security status will be changed to 2 (private level) accordingly: 
\begin{center}
\begin{verbatim}
?AC?Bob@hotmail.com	?CID?2	?HOST?Alice@hotmail.com	?STAT?2
\end{verbatim}
\end{center}

\section{Conclusion}\label{se:conclusion}
There is a need for secure chat room environments via the existing IM infrastructure, and therefore an approach to extend OTR to provide secure chat room support via IM is provided. The proposed approach is useful in addressing the needs of individuals (e.g. small businesses where confidentiality of information is crucial) to have off-the-record and secure meetings with virtually no cost. A proof of concept plug-in for GAIM was developed. Although the current implementation currently supports chat rooms via the MSN IM network, the proposed idea can be extended to support other IM protocols such as Yahoo IM, AOL IM, etc. 

While we realize the additional network traffic introduced by our approach (e.g. the discarded messages), IM messages tend to have small payloads and we chose to accept this slight loss of performance (un-noticeable for four users in a chat room), rather than to deal with the complicated issue of group key-exchanging protocols—particularly in the Deffie-Hellman key agreement protocol. The performance of our key management algorithm remains an issue to be considered. We believe that causing and discarding the additional traffic which is light and in which packets have small payloads, will not hinder the performance as much as a complex group key management protocol would. We are currently working on this problem to find a way to implement an efficient key management system, so we can avoid the excess traffic our approach generates.

\section{Next generation}\label{se:future}
Once more, an issue remains in the implementation is that how to deal with a new user (no matter who invited him/her, could or could be the virtual server). Ideally, the dedicated virtual server should be responsible to respond the change of the secure status due to a new joined member. In another word, when a new user, say Eve, joins the private chat room and breaks the security (i.e. since Eve does not have any shared secrets with any memebers in that chat room), the virtual server, Alice, should react accordingly. Alice should restart the whole key-exchange protocal pairwisely, which is the same process as a fully key refreshment, but including the new memeber, Eve, this time. And after the restablishment of the keys, it becomes a normal OTR chat room session.
In our next version of OTR chat room, we will address this problem in terms of restablish the private convsersation session automatically. Basically,  we have two choice: one, as we said, is to do a full key-refreshment together with the new memeber; and another one is only do a peer-to-peer OTR key-exchange between the virtual server and the new user. Either way could solve this problem, but we perfer the first senario, since it will help to enhance the security.
\note[Remzi]{HOW ABOUT USER 3? AND HOW DO WE STOP SAY USER 2 WHO IS not the server from inviting another user, say user 4?} 
\note[Jiang]{It's not been implemented in my code. Every time, a new user join the chat room, the chat room should be restarted manually. But I think it's pretty easy to make it automatically. So my question is, is it o.k. to put it here? or put it in the future work.}

Our design brings up an additional security issue and it is remaining to be solved. There is always a possibility that the virtual server gets attacked. The virtual server is a full loaded machine gun. It has all the ability, not only to read but also to modify the messages, since it is responsible for delivering them. Hence, if the virtual server turns into a bad guy, it could read messages from a user, modify it, and then transfer it to the other users. We think the integrity of the messages can be assured by maintaining MD5 (any one-way hash table should be applicable) values of the original plain-text messages on each user's computer and verifying them periodically. \change[Jiang]{In order for this approach to work, the chat room participants must be able to transfer the hash signatures of their messages out-of-band (without going through the virtual server). This approach will cause further traffic. Currently, users can establish out-of-band (direct MSN IM) secure OTR sessions and verify if they suspect the virtual server is altering messages. However, an automated way of checking IMs' integrity would be beneficial. We believe this issue can be resolved when a proper solution for group key management protocol is implemented.}{In oder to be simple, we continue with the previous examples: Carol receives a message which is under Bob's name, but how could she verify that and the message has not been changed by Alice? So when Bob says something, he could attach an additonal message digest ( i.e. hash value generated by MD5 alogrithm), a unique identifier (i.e. timestamp) along with the original message. And as we discussed, in MSN IM protocal, messages are broadcast in a chat room session, so that Alice has no control to prevent Carol from receiving the authentic message digest (i.e Carol would not be able to decrypt the message part, but this does not hinder her from getting the message's MD5 hash value. She could simply discard the unreadable message, but keep the hash value). Thus, Carol could use this knowledge to verify the messages' integrity, when she receivies the re-encrypted copy from Alice. In detail, the only thing she needs to do is: decrypts the message from Alice, calculates the MD5 value over the plain-text message and compares this value with the one she gained from Bob. If they are same, which means, Alice has not changed the content of what Bob said; otherwise, Alice has been cheating. This approach will cause further traffic. However, an automated way of checking integrity of messages would be more beneficial than drawback.}

% can use a bibliography generated by BibTeX as a .bbl file
% standard IEEE bibliography style from:
% http://www.ctan.org/tex-archive/macros/latex/contrib/supported/IEEEtran/bibtex
\bibliographystyle{IEEEtran.bst}
% argument is your BibTeX string definitions and bibliography database(s)
\bibliography{IEEEabrv,otrrefs.bib}

% that's all folks
\end{document}


